Operating systems have a systematic way of storing and deleting data. When a file (object) is created in an NTFS volume the location of its sectors, its name, type, and everything that makes up the file is recorded in the Master File Table ($MFT). The $MFT is a core system file organized for file record and attribute analysis that contains information about every file and directory on the volume, including the $MFT itself.
When a file is deleted the icon representing the file is removed from the User's view; there is no suitable verification by the system that the file was truly deleted or removed from the User's computer. From the Users perspective the file is no longer visible; therefore the file is assumed to have been deleted. And given that the User may have used an application designed to overwrite the file data, (at specific offsets with a logical sequence of binary data), there's no questioning that the file has been removed from the User's computer. However when a User attempts to verify if the files were actually deleted, using over-the-counter low-level forensic tools, what puzzles the User is that their “supposed” deleted files are still intact.
What further puzzles the User, is that the same high-end forensic tools used to recover data also offer file removal options, claiming to permanently remove the file, however when the User uses the forensic tool to remove the file and then verifies if the file was deleted, the file again is “completely” intact.
What the user does not know is that applications designed to remove critical data do not remove the file's header or stream descriptors (Attributes) from the $MFT; nor do they execute algorithms that target the removal of the deleted file records possible sensitive data located after End Of Marker (0xFFFFFFFF) to end of file record. They only “attempt” to alter the files data directly and indirectly by bypassing disk cache and on sector boundaries use conventional overwriting techniques to saturate the disk to the greatest depth possible with alternating 0x92, 0x49, 0x24, 0xCC, 0x11, 0x99, 0xAA, 0xB6, 0xDB, 0x6D 0xFF, or 0x00 type byte patterns of binary data.
Secondly; because of public demand, others like Mark Russinovich via “SDelete” have attempted to remove file records (FRS) indirectly by attempting to trick the system; his method of creating as many inline files to force the system to append its $MFT records only slows the systems input/output performance as well as alter the integrity of the NTFS; moreover the saturation of inline files critically ruins the system in the event of a power failure or otherwise; and depending on the state of the $MFT at the time of execution, the saturation of 1 KiB files can cause the system to cease responding to inputs or crash; and further cause and has caused the $MFT $DATA (0x80) attribute to become fragmented thereby forcing the User to reformat to restore system stability or deal with a system that can be unresponsive.
Since the $MFT is not designed to append itself, on file or folder deletion, all pointers that point to overwritten or non-overwritten clusters stay completely intact within the deleted FRS stream descriptors (Attributes) and therefore are open to forensic examination.
The present invention addresses the above limitations allowing a typical User, not skilled in the art of computer forensics, to remove a $MFT FRS in a forensically sound manner thus allowing the “true” removal of a file residing within an NTFS $MFT. Furthermore the present invention increases efficiency within the system and does not hinder performance like previous methods.